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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Access and Terminals (AT). 



Introduction 



To evaluate conformance of a particular implementation, it is necessary to have a statement of which capabilities and 
options have been implemented for a telecommunication specification. Such a statement is called an Implementation 
Conformance Statement (ICS). 
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Scope 



The present document provides the Protocol Implementation Conformance Statement (PICS) proforma for the Network- 
based Call Signalling, Dynamic Quality of Service, Provisioning and Security protocols together with the ETSI V5 
mapping for the IPCablecom (packet-based multimedia communication) system defined in TS 101 909-4 [2], 
TS 101 909-5 [3], TS 101 909-6 [4], TS 101 909-7 [5], TS 101 909-8 [6], TS 101 909-9 [7], TS 101 909-11 [8], 
TS 101 909-23 [10], in compliance with the relevant requirements specified in those specifications and in accordance 
with the relevant guidance given in ISO/IEC 9646-7 [26]. 

The supplier of a protocol implementation which is claimed to conform to is required to complete a copy of the PICS 
proforma provided in annex A of the present document and is required to provide the information necessary to identify 
both the supplier and the implementation. 
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Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the terms and definitions given in TS 101 909-4 [2], TS 101 909-5 [3], 
TS 101 909-6 [4], TS 101 909-7 [5], TS 101 909-8 [6], TS 101 909-9 [7], TS 101 909-11 [8], TS 101 909-23 [10], 
ISO/IEC 9646-1 [25], ISO/IEC 9646-7 [26] and the following apply: 

ICS proforma: document, in the form of a questionnaire, which when completed for an implementation or system 
becomes a PICS 

Implementation Conformance Statement (ICS): statement made by the supplier of an implementation or system 
claimed to conform to a given specification, stating which capabilities have been implemented 

NOTE: The PICS can take several forms: protocol PICS, profile PICS, profile specific PICS, information object 
PICS, etc. 

Protocol ICS (PICS): ICS for an implementation or system claimed to conform to a given protocol specification 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AN Access Network 

BCC Basic Call Control 

CM Cable Modem 

CMS Call Management Server 

CMTS Cable Modem Termination System 

COPS Common Open Policy Service 

DCR Detailed Call Record 

DF Delivery Function 

DQoS Dynamic Quality of Service 

DTMF Dual Tone Multi Frequency 

EMS Event Message Server 

E-MTA Embedded MTA 

GC Gate Coordination 

GCM Gate Coordination Messaging 

HMAC Hashed Message Authentication Code 

ICS Implementation Conformance Statement 

IKE Internet Key Exchange 

IP AT Internet Protocol Access Terminal 

IUT Implementation Under Test 

LCS Line Control Signalling 

LE Local Exchange 

MG Media Gateway 

MIB Management Information Base 

MTA Multimedia Terminal Adapter 

NCS Network-based Call Signalling Protocol 

PDU Protocol Data Unit 

PICS Protocol Implementation Conformance Statement 

PKINIT Public Key INITial 

PSTN Public Switched Telephone Network 

RGI Remote-Gate-Info 

RKS Record Keeping Server 

RTCP Real-Time Transfer Control Protocol 

RTP Real Time Protocol 

SCS System Conformance Statement 

SUT System Under Test 

UDP User Data Protocol 
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Overview 



IPCablecom is conceived as an integrated distributed system of cooperating elements with multi-layered multi-media 
protocols and end to end service support. Thus the structure of the IPCablecom technical specifications do not by nature 
lend themselves to defining the individual elements of the system as isolated components, which request that interfaces 
be clearly and independently identified for conformance testing purposes. Consequently, prior to performing any 
analysis of the complex signalling interactions that take place within the system, each of the physical and logical 
interfaces are identified as they apply to the IP AT. 

The TS 101 909 specifications are not a series of individual standards that were just glued together to make a solution; 
they are a cohesive set of interwoven specifications that jointly evolved to enable the IPCablecom implementations to 
interwork as a cohesive end-to-end system. They are entirely based on cable operator needs and requirements. Any 
changes made to one part have to be done in concert with work being done in other parts. These must be closely 
coordinated to ensure the elements interface together properly. 

For all of the clauses of a given specification, there is a history of evolution and reasoning behind the development of 
PacketCable™ and subsequently IPCablecom.The present document relates to the set of base standards as defined in the 
TS 101 909 series, there is no single base standard that covers the requirements of the IP AT in its entirety. Figure 1 
illustrates the set of TS 101 909 series base standards that have been referred to in order to evaluate an IP AT protocol 
implementation, for the purpose of developing the present document. 



PICS Statements per specification 



100 



10 




■ Pt. 


4NCS 


□ Pt. 


5DQoS 


■ Pt. 


23 IPAT-LCS 



Base specifications 



Figure 1 : Base specifications relevant to the IPAT 



5 Conformance to this PICS proforma specification 

If it claims to conform to the present document, the actual PICS proforma to be filled in by a supplier shall be 
technically equivalent to the text of the PICS proforma given in annex A, and shall preserve the numbering/naming and 
ordering of the proforma items. 

A PICS which conforms to the present document shall be a conforming PICS proforma completed in accordance with 
the guidance for completion given in clause A. 1 . 
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Annex A (normative): 

PICS proforma for ETSI TS 101 909 IPCablecom series 

specific to Internet Protocol Access Terminal 



Notwithstanding the provisions of the copyright clause related to the text of the present document, ETSI grants that 
users of the present document may freely reproduce the PICS proforma in this annex so that it can be used for its 
intended purposes and may further publish the completed PICS. 



A.1 Guidance for completing the PICS proforma 



A.1 .1 Purposes and structure 



The purpose of this PICS proforma is to provide a mechanism whereby a supplier of an implementation of the 
requirements defined in the ETSI IPCablecom [TS 101 909] series may provide information about the implementation 
in a standardized manner. 

The PICS proforma is subdivided into clauses for the following categories of information: 

guidance for completing the PICS proforma; 

identification of the implementation; 

identification of the protocol; 

global statement of conformance; 

V5 to NCS mapping implementation; 

network-based call signalling protocol implementation; 

dynamic quality of service implementation; 

multimedia terminal adapter provisioning implementation; 

management information base implementation; 

implementation of security mechanisms. 

A.1 .2 Abbreviations and conventions 

The PICS proforma contained in this annex is comprised of information in tabular form in accordance with the 
guidelines presented in ISO/IEC 9646-7 [26]. 

Item column 

The item column contains a qualified number which identifies the item in the table. 

Item description column 

The item description column describes in free text each respective item (for example parameters, timers, etc.). It 
implicitly means "is < item description > supported by the implementation?". 
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Status column 

The following notations, defined in ISO/IEC 9646-7 [26], are used for the status column: 

M mandatory - the capability is required to be supported; 

O indicates an optional requirement in ETSI TS 101 909. However, only sending of the 

parameter/message is optional. When the parameter/message is received an ETSI IPCablecom 
compliant E-MTA shall act upon the parameter/message in accordance with the procedures as 
described in the main body of the present document; 

N/A not applicable - in the given context, it is impossible to use the capability; 

X prohibited (excluded) - there is a requirement not to use this capability in the given context; 

Ot.i qualified optional - for mutually exclusive or selectable options from a set. "i" is an integer which 

identifies a unique group of related optional items in the table numbered t and the logic of their 
selection which is defined immediately following the table; 

Ct.i conditional - the requirement on the capability ("m", "o", "x" or "n/a") depends on the support of 

other optional or conditional items, "i" is an integer identifying a unique conditional status in the 
table numbered t, expression which is defined immediately following the table. 

Support column 

The support column shall be filled in by the supplier of the implementation. The following common notations, defined 
in ISO/IEC 9646-7 [26], are used for the support column: 

Y or y supported by the implementation; 

N or n not supported by the implementation; 

N/A, n/a or no answer required (allowed only if the status is n/a, directly or after evaluation of a conditional 

status). 

It is also possible to provide a comment to an answer in the space provided at the bottom of the table. 

NOTE: As stated in ISO/IEC 9646-7 [26], support for a received PDU requires the ability to parse all valid 
parameters of that PDU. Supporting a PDU while having no ability to parse a valid parameter is non- 
conformant. Support for a parameter on a PDU means that the semantics of that parameter are supported. 

Values allowed 

Notes describe the content of the field, when only restricted values are supported, for sent message. 

References to items 

For each possible item answer (answer in the support column) within the PICS proforma a unique reference exists, 
used, for example, in the conditional expressions. It is defined as the table identifier, followed by a solidus character "/", 
followed by the item number in the table. 

EXAMPLE: A.5/4 is the reference to the answer of item 4 in table 5 of annex A. 

Prerequisite line 

A prerequisite line takes the form: Prerequisite: < predicate >. 

A prerequisite line after a clause or table title indicates that the whole clause or the whole table is not required to be 
completed if the predicate is FALSE. 
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A.1 .3 Instructions for completing the PICS proforma 

The supplier of the implementation shall complete the PICS proforma in each of the spaces provided. In particular, an 
explicit answer shall be entered, in each of the support or supported column boxes provided, using the notation 
described in clause A. 1 .2. 

If necessary, the supplier may provide additional comments in space at the bottom of the tables, or separately on sheets 
of paper. 

More detailed instructions are given at the beginning of the different clauses of the PICS proforma. 



A.2 Identification of the implementation 

Identification of the Implementation Under Test (IUT) and the system in which it resides (the System Under Test 
(SUT)) should be filled in so as to provide as much detail as possible regarding version numbers and configuration 
options. 

The product supplier information and terminal information should both be filled in if they are different. 

A person who can answer queries regarding information supplied in the PICS should be named as the contact person. 

A.2.1 Date of the statement 



A.2. 2 Implementation Under Test (IUT) identification 

IUT name: 



IUT version: 

A.2.3 System Under Test (SUT) identification 

SUT name: 

Hardware configuration: 



Operating system: 
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A.2.4 Product supplier 

Name: 



Address: 



Telephone number: 



Facsimile number: 



E-mail address: 



Additional information: 



A.2.5 PICS contact person 

(A person to contact if there are any queries concerning the content of the PICS) 

Name: 



Telephone number: 



Facsimile number: 



E-mail address: 



Additional information: 
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A.3 PICS/System Conformance Statement (SCS) 

Provide the relationship of the PICS with the SCS for the system. 

A. 4 Identification of the protocols to the interfaces on the 
I PAT 

The PICS proforma applies to the following standards: 

ETSI TS 101 909-4 (Vl.2.2): "Digital Broadband Cable Access to the Public Telecommunications Network; IP 
Multimedia Time Critical Services; Part 4: Network Call Signalling Protocol". 

ETSI TS 101 909-5 (VI. 1.1): "Digital Broadband Cable Access to the Public Telecommunications Network; IP 
Multimedia Time Critical Services; Part 5: Dynamic Quality of Service for the Provision of Real Time Services over 
Cable Television Networks using Cable Modems". 

ETSI TS 101 909-6 (VI. 1.1): "Digital Broadband Cable Access to the Public Telecommunications Network; IP 
Multimedia Time Critical Services; Part 6: Media Terminal Adapter (MTA) Device Provisioning". 

ETSI TS 101 909-7 (VI. 1.1): "Digital Broadband Cable Access to the Public Telecommunications Network; IP 
Multimedia Time Critical Services; Part 7: MIB Framework". 

ETSI TS 101 909-9 (VI. 1.1): "Digital Broadband Cable Access to the Public Telecommunications Network; IP 
Multimedia Time Critical Services; Part 9: MIB Signalling". 

ETSI TS 101 909-1 1 (Vl.2.1): "Digital Broadband Cable Access to the Public Telecommunications Network; IP 
Multimedia Time Critical Services; Part 11: Security". 

ETSI TS 101 909-23 (VI. 1.1): "Digital Broadband Cable Access to the Public Telecommunications Network; IP 
Multimedia Time Critical Services; Part 23: Internet Protocol Access Terminal". 
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A.5 Global statement of conformance 

Are all mandatory capabilities implemented? (Yes/No). 

NOTE: Answering "No" to this question indicates non-conformance to the protocol specification. Non-supported 
mandatory capabilities are to be identified in the PICS, with an explanation of why the implementation is 
non-conforming, on pages attached to the PICS proforma. 



A.6 General 



Table A.1 : General implementation by the IPAT 



Item 


Requirement 


Reference 


Status 


Support 


G_1 


Is the IPAT capable of supporting a Media 
Gateway (MG) function, as defined by the 
NCS architecture TS 101 909-4 [2], to enable 
an upgrade from an LCS to NCS 
architecture? 


4 [10] 


O 




G_2 


Does the IPAT implement the CMS Gate 
Controller functions to provide Dynamic 
Quality of Service (DQoS) functions? 


5.2 [10] 


M 




G_3 


Does the IPAT implement IPCablecom 
security as defined in clause 6.8 [10]? 


6.8 [10] 


M 




G_4 


Does the IPAT implement only those 
subscriber line call features as supported 
within the IPCablecom NCS architecture, as 
defined in TS 101 909-4, annex B [2]? 


Annex B [2] 


O 




Comments: 



Table A.2: Trunk management by the IPAT 



Item 


Requirement 


Reference 


Status 


Support 


G_5 


Does the IPAT manage alarms associated to 
its end of the digital trunks? 


5.2 [10] 


M 




G_6 


Does the IPAT manage the initialization 
process associated to its end of the digital 
trunks? 


5.2 [10] 


M 




G_7 


Does the IPAT manage the maintenance of 
its end of the digital trunks? 


5.2 [10] 


M 




G_8 


Does the IPAT manage its own provisioning 
information as needed to support 
inter-working (mapping between LCS and LE 
numbering, trunk identities, etc.)? 


5.2 [10] 


M 




Comments: 
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A. 7 Physical Interfaces 



Table A.3: Physical Interfaces supported by the IPAT 



Item 


Requirement 


Reference 


Status 


Support 


Pl_1 


Does the IPAT support a V5.2 [13] physical 
interface between LE-to-IPAT ? 


6.1 [10] 


M 




Pl_2 


Do the electrical and physical characteristics 
of the V5.2 interface conform to the 
2 048 kbit/s case in EN 300 166 [13]? 


B.3 [2] 


M 




Pl_3 


Does the IPAT implement IEEE 802.3 [19] as 
the physical interface between CMTS-to- 
IPAT? 


6.1 [10] 


M 




Pl_4 


Does the IPAT implement IEEE 802.3 [19] as 
the physical interface between IPAT-to- 
Network Servers? 


6.1 [10] 


M 




Pl_5 


Does the IPAT implement IEEE 802.3 [19] as 
the physical interface between 
IPAT-to-EMS? 


6.1 [10] 


M 




Comments: 
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A.8 V 5.2 Call Signalling Interfaces 



Table A.4: V 5.2 Call signalling implementation by the IPAT 



Item 


Requirement 


Reference 


Status 


Support 


CS_1 


Does the IPAT implement the call signalling 
interface Pkt-c8 (IPAT-LE)? 


6.2 [10] 


M 




CS_2 


Does the IPAT convert NCS protocol call 
control signalling into digital line interface 
signalling (V5.2) required by the LE? 


6.2 [10] 


M 




CS_3 


Does the IPAT implement the call signalling 
interface Pkt-c9 (LE-IPAT)? 


6.2 [10] 


M 




CS_4 


Does the IPAT convert digital line interface 
signalling from the LE (V5.2) into the 
IPCablecom NCS protocol call control 
signalling? 


6.2 [10] 


M 




CS_5 


Does the IPAT implement call signalling 
messages between the IPAT and LE via 
the V5.2 interface? 


6.2 [10] 


M 




CS_6 


Does the IPAT implement In-Band DTMF 
Signalling towards the Local Exchange as 
specified in ES 201 235 [14]? 


6.2 [10] 


M 




CS_7 


Does the IPAT implement Receipt of call 
progress tones and announcements from the 
Local Exchange as specified in 
EG 201 188 [1]? 


6.2 [10] 


M 




CS_8 


Does the IPAT implement Receipt of display 
services protocols from the Local Exchange 
as specified in EN 300 659-1 [1 6]? 


6.2 [10] 


M 




CS_9 


Does the IPAT implement the signalling 
functions of the V5.2 interface as specified in 
EN 300 347-1 [15] from the Local Exchange 
(LE)? 


6.2 [10] 


M 




CS_10 


Does the IPAT support the Access Network 
(AN) functionality of the V5.2 interface for AN 
Data Link Layer Protocols? 


6.2 [10] 


M 




CS_11 


Does the IPAT support the Access Network 
(AN) functionality of the V5.2 interface for the 
AN PSTN Protocol? 


6.2 [10] 


M 




CS_12 


Does the IPAT support the Access Network 
(AN) functionality of the V5.2 interface for the 
AN BCC Protocol? 


6.2 [10] 


M 




CS_13 


Does the IPAT support the Access Network 
(AN) functionality of the V5.2 interface for the 
AN Link Control Protocol? 


6.2 [10] 


M 




CS_14 


Does the IPAT support the Access Network 
(AN) functionality of the V5.2 interface for the 
AN Control Protocol? 


6.2 [10] 


M 




CS_15 


Does the IPAT support the Access Network 
(AN) functionality of the V5.2 interface for the 
AN Protection Protocol? 


6.2 [10] 


M 




CS_16 


Does the IPAT support packetized PSTN 
media flows as both transmitted and 
managed using the RTP and RTCP protocols 
with QoS and security as defined in 
IPCablecom? 


6.2 [10] 


M 




Comments: 
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A.9 Media Flow 



Table A.5: RTP/RTCP signalling implementation by the IPAT 



Item 


Requirement 


Reference 


Status 


Support 


MF_1 


Does the IPAT convert the outgoing RTP 
(voice) packets into digital circuit voice traffic, 
passing it over E1 digital trunks to the LE? 


6.2 [10] 


M 




MF_2 


Does the IPAT convert incoming voice circuit 
traffic presented on E1 digital trunks from LE 
into RTP (voice) packet traffic? 


6.2 [10] 


M 




Comments: 



Table A.6: Media Flow 



Item 


Requirement 


Reference 


Status 


Support 


MF_3 


Does the IPAT implement the IETF standard 
Real Time Transport Protocol 
(RFC 1889 [20]) as the means to transport all 
media streams in the network? 


6.3 [10] 


M 




MF_4 


Does the IPAT implement the RTP profile for 
audio streams as defined in RFC 1890 [21]? 


6.3 [10] 


M 




MF_5 


Does the IPAT implement the RTP profile for 
video streams as defined in RFC 1890 [21]? 


6.3 [10] 


M 




MF_6 


Does the IPAT implement the Session 
Description Protocol (SDP), as given in 
RFC 2327 [23], to communicate the particular 
IP address and UDP port an RTP session is 
using? 


6.3 [10] 


M 




MF_7 


Does the IPAT implement a Payload Header 
Suppression feature for abbreviating common 
headers so that RFC 2833 [24] event packets 
can be padded to match the length of the 
corresponding RTP voice packet? 


6.3 [10] 


M 




Comments: 
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A. 10 V5 Mapping 



Table A.7: V5 Mapping implementation by the IPAT 



Item 


Requirement 


Reference 


Status 


Support 


V5_1 


Does the IPAT translate PSTN V5.2 signalling 
messages into NCS messages as defined in 
the annex B of the NCS specification 
TS 101 909-4 [2]? 


6.2.1 [10] 


M 




V5_2 


Does the IPAT handle the V5.2 control 
requirements as defined in 
EN 300 347-1 [15]? 


6.2.2 [10] 


M 




V5_3 


Does the IPAT provide (via provisioning) an 
internal address translation table from the V5 
User Port Identification Value to the 
associated IP/Line ID address of the CM/MTA 
that is associated with that line number? 


6.10 [10] 


M 




V5_4 


Does the IPAT make the translation, as 
described in V_3.1 , available through a 
provisioning system interface? 


6.10 [10] 


M 




V5_5 


Does the IPAT Detailed Call Record (DCR) 
include the User Port Identification Value for 
each call processed by the IPAT? 


6.10 [10] 


M 




V5_6 


Does the IPAT Detailed Call Record (DCR) 
include the IP/Line ID address values for 
each call processed by the IPAT? 


6.10 [10] 


M 




V5_7 


Does the IPAT map the V5 "Establish" or 
"Signal" Message Types for "Cadence- 
ringing" to the NCS "SignalRequest"? 


B.4.1 [2] 


M 




V5_8 


Does the IPAT map the The V5 "Establish" or 
"Signal" Message Type "Pulsed Signal" 
request to an NCS "SignalRequest"? 


B.4.2 [2] 


M 




V5_9 


Does the IPAT include the timeout value if the 
product of pr*rep is less than 180 seconds? 


B.4.2 [2] 


O 




V5_10 


Does the IPAT include the timeout value if the 
product of pfrep is greater than 180 
seconds? 


B.4.2 [2] 


M 




V5_11 


Does the IPAT implement Line Treatment 
coding as given in table B.2 of 
TS 101 909-4 [2]? 


B.4.2 [2] 


M 




V5_12 


Does the IPAT support mapping of V5 
enumerated pulse type coding to NCS line 
treatment types as defined in the provisioning 
tables of annex B of TS 1 01 909-4 [2]? 


B.4.2 [2] 


M 




V5_13 


Does the IPAT support mapping of V5 
enumerated pulse duration coding to NCS 
line treatment durations in milliseconds as 
defined in the provisioning tables of annex B 
of TS 101 909-4 [2]? 


B.4.2 [2] 
B.4.4 [2] 


M 




V5_14 


Does the IPAT support the NCS requested 
events for pulsed signals, by inclusion in 
the requested events (R) parameter?. 


B.4.3 [2] 


M 




V5_15 


Does the IPAT support the NCS requested 
events (R) parameter oc? 


B.4.3 [2] 


M 




V5_16 


Does the IPAT support the NCS requested 
events (R) parameter of? 


B.4.3 [2] 


M 




V5_17 


Does the IPAT support requested events (R) 
parameter pc? 


B.4.3 [2] 


M 




V5_18 


Does the IPAT implement the pulse 
completion event as defined in annex B of 
TS 101 909-4 [2]? 


B.4.5 [2] 


M 
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A. 11 Dynamic Quality of Service 



Table A.8: DQoS implementation by the IPAT 



Item 


Requirement 


Reference 


Status 


Support 


DQoS_1 


Does the IPAT verify that the CMTS has 
correctly reported the completion of all calls? 


6.6.3 [10] 


M 




DQoS_2 


Does the IPAT verify that QoS resources 
were released at the moment that the CMTS 
reported completion of all calls? 


6.6.3 [10] 


M 




DQoS_3 


Does the IPAT support forcing the release of 
QoS resources as given in clause 6.6.3 [10]? 


6.6.3 [10] 


M 




DQoS_4 


In the case of abnormal disconnect as given 
in clause 6.6.3 [10], does the IPAT support 
V 5.2 call release message notifications to the 
LE? 


6.6.3 [10] 


M 




DQoS_5 


Does the IPAT establish DQoS Gates for 
every voice call by initiating DQoS GATE- 
SET message exchanges with the CMTS? 


6.6.4.1 [10] 


M 




DQoS_6 


Does the IPAT send the GatelD, signalled in 
NCS connection commands, to the MTA in 
subsequent resource reservation and 
committal message exchanges with the 
CMTS? 


6.6.4.1 [10] 


M 




DQoS_7 


Does the IPAT protect against denial of 
service attacks as given in 
clause 6.6.4.1.7 [10]? 


6.6.4.1.7 [10] 


M 




DQoS_8 


Does the IPAT signal the CMTS that Event 
Messages should not be generated for 
IPAT-initiated voice calls as given in 
clause 6.6.4.2 [10]? 


6.6.4.2 [10] 


M 




DQoS_9 


Does the IPAT establish DQoS Gates for 
every voice call by initiating DQoS GATE- 
SET message exchanges with the CMTS as 
given in clause 6.6.4.2 [10]? 


6.6.4.2 [10] 


M 




DQoSJO 


Does the IPAT-generated Gate-Specs object 
contain the MTA IP address in the 
appropriate positions for the upstream and 
downstream Gates, as given in 
clause 6.6.4.2 [10]? 


6.6.4.2 [10] 


M 




DQoSJ 1 


Does the IPAT-generated Gate-Specs object 
contain the IPAT IP address in the 
appropriate positions for the upstream and 
downstream Gates, as given in 
clause 6.6.4.2 [10]? 


6.6.4.2 [10] 


M 




DQoS_12 


Does the IPAT-generated Gate-Specs object 
contain the IPAT receive UDP port as the 
destination port of the upstream Gate, as 
given in clause 6.6.4.2 [10]? 


6.6.4.2 [10] 


M 




DQoS_13 


Does the IPAT-generated Gate-Specs object 
set the MTA UDP Port to zero, in the 
appropriate positions for the upstream and 
downstream Gates, as given in 
clause 6.6.4.2 [10]? 


6.6.4.2 [10] 


M 




DQoS_14 


Does the IPAT ensure that DQoS Gates it 
established have been properly closed by the 
CMTS for every voice call? 


6.6.4.2 [10] 


M 




DQoS_15 


Does the IPAT ensure that it minimizes the 
possibility of deleting any Gates, as given in 
clause 6.6.4.2 [10]? 


6.6.4.2 [10] 


M 
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Item 


Requirement 


Reference 


Status 


Support 


DQoS_16 


Does the IPAT generate (via provisioning) an 
internal address translation table to map the 
V5 User Port Identification Value to the 
associated IP/Line ID address of the CM/MTA 
associated with that line number? 


6.10 [10] 


M 




DQoS_17 


Does the IPAT make the the internal 
translation table (see Q_1 6) accessible via a 
provisioning system interface? 


6.10 [10] 


M 




DQoS_18 


Does the IPCablecom Access Network 
provide timely reporting to the LE of the loop 
state at the CM/MTA to enable accurate 
billing to be accomplished? 


B.1 [10] 


M 




DQoS_19 


Does a trust relationship exist between 
GC/IPAT and CMTS with respect to 
admission and authorization? 


5.4 [3] 


M 




Comments: 



Table A.9: Implementation of DQoS Gate Co-ordination by the IPAT 



Item 


Requirement 


Reference 


Status 


Support 


DQoS_20 


Does the IPAT implement the DQoS Gate 
Control interface as specified in 
TS101 909-5 [3]? 


6.6.4.2 [10] 


M 




DQoS_21 


Does the IPAT support DQoS Gate Control 
Messages as given in clause 6.9.3.1.1 [10]? 


6.6.4.2 [10] 


M 




DQoS_22 


Does the IPAT support DQoS Gate Control 
Objects as given in clause 6.9.3.1.1 [10]? 


6.6.4.2 [10] 


M 




DQoS_23 


Does the IPAT support the "without gate 
coordination option" as given in 
clause 6.6.3 [10]? 


6.6.3 [10] 


09! 




DQoS_24 


Does the IPAT support the "with gate 
coordination option" as given in 
clause 6.6.3 [10]? 


6.6.3 [10] 


09! 




Comments: 

NOTE: 09i: At least one of these options must be supported by the IPAT. 



Table A.10: Implementation of DQoS Without Gate Co-ordination Option by the IPAT 

Prerequisite: Support of the "without gate coordination option" [item DQoS_23] 



Item 


Requirement 


Reference 


Status 


Support 


DQoS_25 


During abnormal situations as described in 
clause 6.6.3 [10], does the IPAT/GC close 
"open gates" to the CMTS? 


6.6.3 [10] 


M 




DQoS_26 


Does the IPAT verify that Gates have been 
closed in all call release scenarios? 


6.6.4.1.5 [10] 


M 




DQoS_27 


Does the IPAT delete the Gates that have not 
been properly closed? 


6.6.4.1.5 [10] 


M 




Comments: 



ETSI 



21 



ETSI TS 102 318 V1.1.1 (2004-03) 



Table A.11 : Implementation of DQoS With Gate Co-ordination Option by the IPAT 

Prerequisite: Support of the "with gate coordination option" [item DQoS_24] 



Item 


Requirement 


Reference 


Status 


Support 


DQoS_28 


During abnormal situations as described in 
clause 6.6.3 [10], does the IPAT/GC support 
requests for Gate information to the CMTS? 


6.6.3 [10] 


M 




DQoS_29 


During abnormal situations as described in 
clause 6.6.3 [10], does the IPAT/GC support 
requests to the CMTS to close Gates? 


6.6.3 [10] 


M 




DQoS_30 


Does the IPAT verify the reason for the Gates 
Closure, in abnormal cases, when the Gate 
has not been closed because of an explicit 
disconnect message from the LE (via V 5.2 
interface)? 


6.6.4.1.6 [10] 


M 




DQoS_31 


Does the IPAT notify the LE about call cut off 
(by sending V 5.2 AN Fault message)? 


6.6.4.1.6 [10] 


M 




DQoS_32 


Does the IPAT implement the Gate 
Coordination Messaging as given in 
clause 6.9.3.1.5 [10]? 


6.6.4.2 [10] 


M 




DQoS_33 


Does the IPAT-generated Remote-Gate- Info 
object contain the IPAT/CMTS Proxy IP 
address as given in clause 6.6.4.2 [10]? 


6.6.4.2 [10] 


M 




DQoS_34 


Does the IPAT-generated Remote-Gate- Info 
object contain the UDP port number as given 
in clause 6.6.4.2 [10]? 


6.6.4.2 [10] 


M 




DQoS_35 


Does the IPAT provide message integrity 
using an application-layer (Radius) 
authenticator distributed by COPS? 


6.8.3 [10] 


M 
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A. 12 Security 



Table A.12: Implementation of Security mechanisms 



Item 


Requirement 


Reference 


Status 


Support 


Sec_1 


Is the IPAT Line Control Signalling (LCS) 
Security architecture implementation based on 
the IPCablecom Security Specification 
TS 101 909-11 [8]? 


6.8 [10] 


M 




Sec_2 


Does the IPAT not implement the Record 
Keeping Server (RKS) and its interfaces to the 
CMS and CMTS? 


6.8 [10] 


M 




Sec_3 


Does the IPAT not implement the Delivery 
Function (DF) and its interfaces to the MG, 
CMS, and CMTS? 


6.8 [10] 


M 




Sec_4 


Does the IPAT not implement the Record 
Keeping Server (RKS) and its interfaces to the 
CMS and CMTS? 


6.8 [10] 


M 




Sec_5 


Does the IPAT Gate Controller implement the 
COPS protocol to download QoS policy into 
the CMTS? 


6.8.2.2 [10] 


M 




Sec_6 


Does the IPAT Gate Controller implement the 
Radius protocol to coordinate the QoS 
reservation? 


6.8.2.2 [10] 


M 




Sec_7 


Does the IPAT encrypt RTP and RTCP 
signalling packets? 


6.8.2.4 [10] 


M 




Sec_8 


Is bearer channel traffic passed directly 
between an MTA and the IPAT MG using RTP 
and RTCP secured as defined in ETSI 
Technical Specification TS 101 909-11 [8]? 


6.8.2.5 [10] 


M 




Sec_9 


Does the IPAT respect the requirement to 
encrypt End-to-end RTP media packets 
between the E-MTA and IPAT? 


6.8.3 [10] 


M 




Sec_10 


Does the IPAT use HMAC (Hashed Message 
Authentication Code) to provide message 
integrity? 


6.8.3 [10] 


M 




Sec 11 


Does the IPAT use randomly generated keys? 


6.8.3 [10] 


M 




Sec_12 


Does the IPAT exchange those randomly 
generated keys between the two endpoints 
inside the signalling messages via the IPAT 
CA? 


6.8.3 [10] 


M 




Sec_13 


Does the IPAT encrypt RTCP messages using 
the same secret negotiated during the RTP 
key management? 


6.8.3 [10] 


M 




Sec_14 


Does the IPAT implement NCS message 
integrity and privacy using IPSec? 


6.8.3 [10] 


M 




Sec_15 


Does the IPAT respect the requirement to use 
Kerberos with PKINIT (public key initial 
authentication) extension for Key 
management? 


6.8.3 [10] 


M 




Sec_16 


Is the IPAT implementation of the Gate Control 
protocol, between the IPAT GC and the 
CMTS, based upon COPS? 


6.8.3 [10] 


M 




Sec_17 


Does the IPAT implement the Gate Control 
protocol message integrity and privacy using 
IPSec? 


6.8.3 [10] 


M 




Sec_18 


Does the IPAT respect the requirement to use 
IKE with pre-shared key for Key management? 


6.8.3 [10] 


M 
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A. 13 Network-based call signalling protocol 



Table A.13: NCS Protocol 



Item 


Requirement 


Reference 


Status 


Support 


NCS_1 


Does the IPAT implement the call signalling 
interface Pkt-c1 (MTA-IPAT)? 


6.2 [10] 


M 




NCS_2 


Does the IPAT implement the call signalling 
interface Pkt-c10 (IPAT-MTA)? 


6.2 [10] 


M 




NCS_3 


Does the IPAT implement the call signalling 
messages as defined in annex A and B of 
TS101 909-4 [2]? 


6.2 [10] 
Annex A [2] 
Annex B [2] 


M 




NCS_4 


Does the IPAT instruct the gateways to create 
connections between endpoints as given in 
clause 5 [2]? 


5 [2] 


M 




NCS_5 


Does the IPAT instruct the gateways to detect 
certain events as given in clause 5 [2]? 


5 [2] 


M 




NCS_6 


Does the IPAT implement the NCS protocol as 
defined in TS 101 909-4 [2]? 


6.1 [2] 


M 




NCS_7 


Does the IPAT support text endpoint names of 
the form local-endpoint-name@domain-name? 


6.1.1 [2] 


M 




NCS_8 


Does the IPAT support wildcarding in text 
endpoint names? 


6.1.1 [2] 


M 




NCS_9 


Does the IPAT support character restriction in 
text endpoint names? 


6.1.1 [2] 


M 




NCS_10 


Does the IPAT support slash naming in text 
endpoint names? 


6.1.1 [2] 


M 




NCS_1 1 


Does the IPAT ensure that call identifiers are 
unique within the collection of call agents that 
control the same gateways? 


6.1.2 [2] 


M 




NCS_12 


Does the IPAT support Connection identifiers 
with a maximum length of 32 characters? 


6.1.3 [2] 


M 




NCS_13 


Does the IPAT respect the requirement to wait 
for a period >3 minutes between the end of a 
connection that used a Connection identifier 
and its use in a new connection for the same 
endpoint? 


6.1.3 [2] 


M 




NCS_14 


Does the IPAT support loading of digit maps 
as per the NCS protocol [2]? 


6.1.5 [2] 


M 




NCS_15 


Does IPAT support the NCS packet concept, 
providing unique package names as defined in 
the NCS specification [2]? 


6.1.6 [2] 


M 




NCS_1 6 


Does IPAT support the NCS packet concept, 
providing unique name space for events as 
defined in the NCS specification [2]? 


6.1.6 [2] 


M 




NCS_1 7 


Does IPAT support the NCS packet concept, 
providing unique name space for signals as 
defined in the NCS specification [2]? 


6.1.6 [2] 


M 




NCSJ8 


Does the IPAT support the IETF SDP 
protocol [23] to provide the gateways with the 
description of connection parameters? 


6.2 [2] 


M 




NCS_1 9 


Does the IPAT keep track of the state of the 
endpoint? 


6.4 [2] 


M 




NCS_20 


Does the IPAT keep track of the state of the 
endpoint during the restart procedure? 


6.4 [2] 


M 




NCS_21 


Does the IPAT keep track of the state of the 
endpoint during the failover procedure? 


6.4 [2] 


M 




NCS_22 


Does the IPAT support handover conflict 
resolution between separate call agents? 


6.4.1 [2] 


O 




NCS_23 


Does the IPAT maintain a list of the responses 
sent to recent transactions? 


6.4.1 [2] 


M 




NCS_24 


Does the IPAT maintain a list of the 
transactions that are currently being executed? 


6.4.1 [2] 


M 
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Item 


Requirement 


Reference 


Status 


Support 


NCS_25 


Does the IPAT support retransmission as 
required in clause 6.4.2 [2]? 


6.4.2 [2] 


M 




NCS_26 


Does the IPAT support detection of lost 
associations as required in clause 6.4.2 [2]? 


6.4.2 [2] 


M 




NCS_27 


Does the IPAT handle race conditions to the 
MTA as required in clause 6.4.3 [2]? 


6.4.3 [2] 


M 




NCS_28 


Does the IPAT respect the requirement to 
prove the response to a successful Notify 
message and the new NotificationRequest in 
the same datagram using the piggy-backing 
mechanism, as specified in the quarantine 
function of the MTA? 


6.4.3.1 [2] 


M 




NCS_29 


Does the IPAT support the ordering of 
Commands to the MTA as per 
clause 6.4.3.4 [2]? 


6.4.3.4 [2] 


M 




NCS_30 


Does the IPAT support the Treatment of 
Disorder as per clause 6.4.3.4 [2]? 


6.4.3.4 [2] 


M 




NCS_31 


Does the IPAT implement the 
CreateConnection command transaction? 


7 [2] 


M 




NCS_32 


Does the IPAT implement the 
ModifyConnection command transaction? 


7 [2] 


M 




NCS_33 


Does the IPAT implement the 
DeleteConnection command transaction? 


7 [2] 


M 




NCS_34 


Does the IPAT implement the 
NotificationRequest command transaction? 


7 [2] 


M 




NCS_35 


Does the IPAT implement the Notify command 
transaction? 


7 [2] 


M 




NCS_36 


Does the IPAT implement the AuditEndpoint 
command transaction? 


7 [2] 


M 




NCS_37 


Does the IPAT implement the AuditConnection 
Notify command transaction? 


7 [2] 


M 




NCS_38 


Does the IPAT implement the 
RestartlnProgress command transaction? 


7 [2] 


M 




NCS_39 


Does the IPAT implement the message syntax 
described in clause 5? 


7 [2] 


M 




NCS_40 


Does the IPAT guarantee that transaction 
identifiers for commands sent to a given 
embedded client are unique for the maximum 
lifetime of the transactions within the collection 
of Call Agents that control that embedded 
client, and provide a synchronizing mechanism 
between multiple IPATs to support this? 


7.2.1.2 [2] 


M 




NCS_41 


Does the IPAT support case insensitive names 
for endpoints, parameter names , parameter 
values and connections? 


7.2.1.3 [2] 
7.2.2 [2] 


M 




NCS_42 


Does the IPAT support protocol version 
coding? 


7.2.1.4 [2] 


M 




NCS_43 


Doet the IPAT support the mandatory 
provide mandatory parameters before optional 
ones? 


7.2.2 [2] 


M 




NCS_44 


Does the IPAT support for commands the 
mandatory and optional parameter names and 
commands and the mapping as defined in the 
tables and the clauses TS 101 909-4 [2]? 


7.2.2 [2] 


M 




NCS_45 


Does the IPAT support for responses the 
mandatory and optional parameter names and 
commands and the mapping as defined in the 
tables and the clauses TS 101 909-4 [2]? 


7.3 [2] 


M 




NCS_46 


Does the IPAT support the CASE SENSITIVE 
session description is encoded in conformance 
with the session description protocol (SDP) 
RFC 2327 [23] as per clause 5.4 


7.4 [2] 


M 




NCS_47 


Does the IPAT always explicitly state the 
MGCP port to use in NCS messages (and not 
rely on the default)? 


7.5.1 [2] 


O 
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Item 


Requirement 


Reference 


Status 


Support 


NCS_48 


Does the IPAT support the MTA 
retransmission strategy as given in 
clause 5.5.2 [2]? 


7.5.2 [2] 


M 




NCS_49 


Does the IPAT support piggybacking as 
defined in clause 7.6 [2]? 


7.6 [2] 


M 




NCS_50 


Does the IPAT share the same transaction 
number space with all other IPATs and 
E-MTAs? 


7.7 [2] 


M 




NCS_51 


Does the IPAT confirm completed transaction 
and NOT confirm provisional responses? 


7.7 [2] 


M 




NCS_52 


Does the handle provisional responses from 
the MTA as per clause 7.8? 


7.8 [2] 


M 
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